Team work

Какие общие артефакты есть у команды исследователей?

Представьте, вы работаете в огромной команде над каким-то исследованием в области анализа данных. Собственно, вопрос, какие были бы общие артефакты у этой команды? Чем бы вам понадобилось делиться с коллегами по работе?

Общие артефакты

. . .

• Общие договоренности.

. . .

• Задачи, план исследований.

. . .

• Код, окружение, среда выполнения.

. . .

• Знания(отчеты об исследованиях).

. . .

• Исходные, подготовленные данные и модели.

Во-первых, это общие договоренности: ролевая модель, различные процессы, требования. То есть некоторые условности, которые приняты в команде, для решения спорных моментов и некоторой унификации артефактов, кода, задач и отчетов.

Во-вторых, это задачи. В команде нужно как-то организовать рабочий процесс, разделить ответственность и обязанности на членов команду, выбрать основные направления для исследования, определить ключевые точки в исследованиях. Это все нужно сделать что бы каждый член команды знал, что ему нужно делать, какие эксперименты проводить, какой код писать. При этом нужно организовать так что бы обязанности не дублировались или дублировались по минимуму.

В-третьих, код и окружение. Вам всем придется писать код для экспериментов, переиспользовать его, поддерживать, периодически обновлять и перезапускать. Кроме написания кода, вам придется этот код запускать, для этого нужно воспроизводимое окружение, а лучше общая инфраструктура.

В-четвертых, это знания полученные в ходе исследования. Их нужно фиксировать, обновлять, версионировать и передавать команде. Вот, например, сотрудник проводил важные эксперименты, но вышел в отпуск или заболел, нужно как-то его знания о проведенных исследованиях, полученных результатах и сформулированных выводах. Для всего этого надо как-то управлять знаниями.

В-пятых, нужно решить с большими и громоздкими артефактами — данными и моделями, их нужно как-то хранить и версионировать, а еще делиться с коллегами. Более того нужно писать такой код, который бы выдавал воспроизводимые результаты, всегда один и тот же бинарный объект или массив данных.

Общие договоренности Contributing

Уделим время общим договорённостям. Эта штука давно сформировалась в области разработки ПО. Большое развитие формированию и фиксированию договоренностей дало появление free software и opensource. Проекты, над которыми трудилось множество разных людей из разных стран требовали каких-то общих договоренностей, что успешно развиваться. Появилось понятие contributing - содействие, реализовывалось оно очень топорно, создавался файл contributing в котором описывалось как можно содействовать проекту, давайте глянем на несколько популярных проектов.

Примеры Contributing

• python devguide
• contribute to scipy
• sklearn contributing
• contribute to tensorflow

Как видите в них описывалось все, начиная от того, как развернуть проект, как оформить merge request, как написать документацию к изменениям, заканчивая часами работы core developers и тем как отвечать на вопросы в stack overflow.

Довольно обширные своды правил и информации как разрабатывать проект. Такие практики стоит перенимать и задействовать в своих командах.

Что стоит включать в договоренности?

Все где возникают разногласия в команде

• Как и куда писать код
• Как и куда писать тесты
• Как настроить среду разработки
• Как и куда писать документацию
• Как и куда сохранять данные
• Как и где составлять задачи
• Как брать задачу на себя
• Как оформлять merge requests
• Кто за что отвечает
• У кого можно получить помощь по процессам
• Какие инструменты можно и нельзя использоваться
• Как этими инструментами пользоваться
• Как организован CI в проекте
• Что писать в комитах
• Как происходит починка багов
• Какой у проекта development cycle
• У кого можно получить помощь по процессам

и многое другое.

Все это стоит фиксировать и поддерживать в актуальном состоянии. Это полезно. Полезно по двум причинам:

• Кейс первый. Вы работаете с Петей и Васей. Вы договорились с Васей писать код в стиле А и начали работать. Петя об этом не знает и пишет его по-своему, в стиле Б. Когда вы объединяете свои наработки, у вас получается не консистентный код, в одном модуле функции и классы, в другом весь код написан в глобальной области как один скрипт. Получается, что текущие наработки нужно будет рефакторить и приводить в порядок. А все это произошло потому что информация не была передана всем участникам команды. Если вы о чем-то договорились, то это стоит зафиксировать в общедоступном месте и донести до всех членов команды.

• Кейс второй. К вам в команду пришел новый сотрудник. Для того что бы рассказать ему все и помочь настроить проект вам потребуется несколько дней с ним общаться и передавать знания. При этом важно ничего не забыть. Но если все договоренности зафиксированы, то сотрудник сможет сам разобраться с этим и к вам придет уже с конкретными вопросами.

Мы договорились, но договоренности не соблюдаются

Такое тоже бывает и это нормально. Есть две причины такого события:

• Договоренности заключены — просто потому что, то есть за самими договоренностями не было какой-то идеи, не проводился сравнительный анализ альтернатив, просто диктатор проекта сказал, что с сейчас все будет так, а не иначе. И если эти договоренности не исполняются нужно их пересмотреть.

• Договоренности неудобно исполнять. Тут выхода два, либо пересмотреть их, либо же найти инструменты или способ для упрощения их исполнения, например, автоматизация заполнения чего-то, или автоматизация, проверок, или шаблоны. Выходов много, но нужно подумать, какой будет лучше.

Если какие-то договоренности неудобно исполнять, они занимают много времени, то стоит приостановить их действие, пока исполнение не упроститься.

Резюме

• Договоренности фиксируются в общедоступном месте.
• Договоренности несут пользу процессу и членам команды.
• Договоренности можно отменять, если они мешают команде.

Задачи

Еще одним важным артефактом команды являются задачи. В отличие от классической разработки, где оценка задачи по времени не представляет особых трудностей, в задачах, связанных с исследованиями и экспериментами все куда сложнее, потому что вам заранее не известен результат и способ его достижения. В любом исследовании необходимо подтвердить гипотезу или же опровергнуть, но существует множество методов для этого, и никто изначально не знает какой метод позволит провести проверку гипотезы корректно. Например, корреляция, она позволяет обнаружить зависимость между двумя случайными величинами, но вопрос в том, какую именно зависимость вы ищете? Линейную? Квадратичную? А может быть один из признаков надо сначала логарифмировать? Собственно, есть множество вариантов того, что надо сделать с данными что бы что-то получить. Грамотно составленные задачи позволяют уменьшить количество вариантов для исследования. Поэтому сейчас мы немного об этом поговорим.

Defenition of ready (DoR)

• Мотивация появления задачи.
• Проверяемая гипотеза.
• На каких данных проводить исследование.
• Описание действий для обработки данных.
• Конкретный ожидаемый результат.

Важно иметь список критериев, описывающий состояние задачи, когда ее можно взять в работу. Поскольку задачи в проекте могут возникать не только от тимлида, но и от самих исследователей, так как во время эксперимента были выявлены какие-то аномалии в данных или же необходимо проверить какие-то дополнительные гипотезы, нужно, что бы такие договоренности были в команде и все могли формировать достаточно подробные задачи.

В задаче стоит указать, почему она вообще появилась и какой impact она сделает для проекта, например, в проекте по классификации электронных сообщений проводилось исследование по ключевым словам для каждой темы, в какой-то теме ключевыми словами стали здравствуйте и привет, соответственно в проекте появилась задача по удалению приветствий и в ней стоит упомянуть причину ее появления.

Нужно указать проверяемую гипотезу, то есть что именно нужно проверить в ходе исследования. Например, проверить наличие зависимости между признаками, или выбор стратегии заполнения пропусков для такого-то признака, или выделение ключевых слов на основе какого-то подхода, или же построение такой-то модели на данных проекта.

Так же важно указать какие данные стоит использовать в исследовании, потому что если в проекте хранятся промежуточные версии данных, то сложно с ходу разобраться, а какая из них нужна для проверки гипотезы.

Если нет готовых данных или задача заключается в обработке данных, то нужно описать какие действия нужно предпринять для подготовки данных, что бы исполнитель задачи не догадывался как нужно объединить два датасета что бы получилась корректная выборка.

Ну и последнее конкретный результат, то есть что вы ожидаете при выполнении задачи, например, если вернутся к примеру, про классификацию писем, то ожидаемый результат, что приветствия пропадут из списков ключевых слов, или же какая-то модель получит более высокие метрики. То есть, что вы, как автор задачи, ожидаете после ее исполнения.

Если вы как автор не можете сформулировать такую задачу и для нее нужны дополнительные знания, то стоит сначала создать задачу для получения этих знаний, например, задача по выбору источника данных погоды или же задача по исследованию применения нейростей определенной архитектуры в задачах определенной тематики.

Типы задач

• Задачи обработки данных.
• Задачи проведения исследований.
• Вспомогательные задачи.

Задачи обработки данных появляются в основном на первых этапах исследования и связаны с очисткой и подготовкой датасета. Постановка такой задачи должна содержать:

• мотивацию для появления этой задачи, зачем она нужна, как будет использоваться результат;
• название предполагаемого(ых) датасета(ов) для выполнения, в процессе работы исполнитель может их изменить при необходимости (если поймет, что есть данные более подходящего формата);
• описание действий над данными: фильтрация, очистка, заполнение пропусков, объединение и тд.
• при необходимости фиксируются параметры или же ссылки на участки кода, которые необходимо применить;
• дополнительная известная информация, касающаяся данной задачи.

Задачи проведения исследований описывают постановку исследования, такие задачи составляют наибольшую часть всех задач и появляются на протяжении всего проекта. В описании карточки необходимо указать:

• направление исследования, в какой области мы копаемся;
• проверяемую гипотезу в рамках исследования;
• ожидаемый результат, что подтвердит выдвинутую гипотезу.

Вспомогательные задачи появляются на протяжении всего проекта, они связаны с различными дополнительными работами или исправлением багов. В постановке такой задачи описывается или баг, или работы, которые надо провести. Для описания бага стоит отметить:

• В чем заключается баг?
• Как его воспроизвести?
• Где проблема в коде? В отчете?
• Какие файлы надо изменить?
• Что надо настроить и как?

Defenition of Done (DoD)

• Составлен отчет о проведенном исследовании.
• Код соответствует принятым стандартам качества.
• Для новой функциональности написаны тесты.
• Пройдено ревью кода и исследования.

DoD - Состояние задачи, когда она готова. Членам команды так же важно понимать, что нужно сделать что бы считать задачу выполненной.

Это знание необходимо что бы понимать, какой объем работ нужно провести для выполнения задачи, помимо самого исследования, потому что, напоминаю, вы работаете в команде и важно не только провести исследование, но и составить для него описание, которое позволило бы делиться знаниями с другими членами команды, привести в порядок код и оттестировать его.

На слайде приведен пример что может быть в DoD, в целом эта договоренность формируется также командой и все члены команды должны понимать зачем им это нужно.